Modern businesses rely upon a myriad of operational systems that generate data. Examples of operational systems may include order generation systems, invoicing systems, billing systems and accounting systems. It is often desirable to store data generated by an online transaction processing (“OLTP”) system or an operational system for later analysis. For example, it may be desirable to store data for transactions generated in an OLTP system. At some later point in time, this data may be analyzed to examine customer trends, preferences, revenue generated by category, or other relevant business data. Data visualization tools such as charting and plotting may be employed to provide additional insight into the content of the data. Systems that are utilized to store data generated from operational systems are often referred to as OLAP systems, which may include business warehouse (“BW”) systems or business intelligence (“BI”) systems.
The process of performing the transfer of data from an OLTP system to an OLAP e.g., BW, system is often referred to as an extraction process. The term “extraction” describes the concept of retrieving data from an operational system and causing the storage of the extracted data in an OLAP system. An extraction system may be deployed, which upon the generation of data in an OLTP system, automatically transfers the generated data from an OLTP system to the OLAP system. The extraction process may also perform some rudimentary transformations on the data before it is stored in the OLAP system in order that the data is in a form suitable for processing and storage by an OLAP system. An extraction system may be part of an operational system such as a framework implemented within an operational system or may be a separate system.
Data may be stored in an OLAP system in a very different format than the way data is represented in an OLTP system. This difference may be necessitated by efficiency requirements for enabling analytic processing that will later be performed on data. The data is stored in the OLAP system in a manner that provides for efficient access and storage of the data and facilitates analytical processing performed on the data.
In business systems it is often desirable to track what is commonly referred to as document flow (“Docflow”). Docflow relates to the actual business documents that are typically generated over the life cycle of a business transaction. For example, the evolution of a sales transaction may include the following generally sequential steps: campaign, lead, opportunity, quotation, sales order and invoice. Each of these steps may be associated with corresponding documents, document types, templates, or other recordings of occurrences associated with a particular step of a business transaction. At least some of the steps may generally proceed in a sequence, e.g., a sales campaign may lead to multiple leads, some of which may lead to corresponding opportunities, and some of these may result in providing a quotation. Of course, a campaign may spread over a period of time and may be considered to encompass some or all of the other steps, and the steps may proceed in an iterative or recursive manner, as well (e.g., when a quotation is initially turned down, a revised quotation is accepted, and a sales order ensues).
There may exist multiple predecessor documents for a single successor document, or multiple successor documents for a single predecessor document. This situation may be referred to as “multiplicities”. The term “multiplicities” refers to the situation in which multiple documents are related to or associated with any one document. A multiplicities situation may be represented by the symbols “l:n” to indicate that a single document is associated or related to an arbitrary number (n) of other documents. The relations may include such ontological concepts as “preceding” or “succeeding” or “has a”. For example, there may exist several quotations that precede a single sales order.
The OLAP model requires attributes to be single valued. In order to take account of multiplicities, the multiplicities must be modeled in a specific manner. Thus, it is not possible to represent multiple predecessor documents for a single successor document in a reasonable and efficient manner (without introducing other disadvantages). This limitation may arise, for example, due to a requirement that fields in an OLAP system often must be single valued. That is, the data in any given field must be unique. For example, the star system used to represent data in an OLAP system, may prohibit multiple valued fields.
Thus, the requirements of OLAP storage formats thus impose limitations on adequately representing, analyzing and reporting DocFlow or other data management scenarios that may involve multiplicities. These multiplicities may manifest as multiple predecessor documents for a single successor document, multiple successors for a single predecessor document or some other multitude of documents associated with a single document (1:n). Without accurate representation of multiplicities of DocFlow in an OLAP system, analytics reporting functions may produce incorrect results. For example, if a number of quotations preceded a sales order, but only some subset (or one) of these quotations may be represented in an OLAP storage format, then analytics regarding quotations relative to sales orders may be inaccurate or incomplete. Thus, it may be difficult to provide for the storage of data in an OLAP system in a manner compatible with the requirements of an OLAP system while at the same time allowing for the accurate representation, analysis and reporting of multiplicities that may arise in DocFlow or similar applications.